Shared resources are commonplace in modern data processing systems. Generally speaking, a shared resource consists of any (logical and/or physical) component, which can be accessed by multiple exploiters in turn. An example of shared resource is a server computer (or simply server), which offers a corresponding service to a large number of users accessing the server by means of their client computers (or simply clients). A typical application of the above-described client/server architecture is in Digital Asset Management (DAM) applications.
A problem of the servers (and more generally of any shared resources) is that they are intrinsically limited. For example, the users that are allowed to access each server concurrently cannot exceed a predefined maximum number. This limitation may be due to either objective or subjective constraints. Indeed, the processing capability of the server defines the number of connection sessions that can be established (between the server and the clients) for managing the corresponding accesses. In addition or in the alternative, the number of concurrent accesses may be reduced to ensure an adequate level of quality of the offered service, or according to specific license agreements (for example, relating the cost of the service to the number of concurrent accesses). In any case, after reaching the maximum number of concurrent accesses, any request to access the server by a further user is refused.
In order to mitigate this problem, the server typically implements a time-out mechanism. For this purpose, the server measures an idle time of each user accessing the server. When the idle time of the user reaches a time-out period, the corresponding access is released. In this way, it is possible to avoid keeping the server busy with useless connection sessions.
Typically, the time-out mechanism is implemented by means of a timer for each connection session (which timer is reset whenever the corresponding user submits any command to the server). Different optimization techniques are also available to facilitate the management of those timers. For example, U.S. Pat. No. 7,050,940 discloses a solution for efficiently managing a high number of timers for each connection session. For this purpose, the cited document proposes maintaining a global timer for each connection session, which global timer stores the value of the corresponding timer that will expire sooner; this reduces the time required to maintain and check the timers (since only the global timer needs to be processed for each connection session).
However, in this case as well further accesses to the server may not be granted (after reaching the maximum number of concurrent accesses) until the expiration of the first time-out period. This strongly limits the availability of the server; the problem is particular acute in applications (such as of the DAM type), which should guarantee the access to the server to the largest possible number of different users in any situation (for example, even in the case of a peak of access requests).
A different approach is instead based on the recycling of the connection sessions. In this case, each connection session processes the commands submitted by different users accessing the server in succession; these commands are maintained in a global queue, so as to be processed by the first connection session that is available. Particularly, as described in U.S. Pat. No. 6,988,140, once a user has become idle (since she/he has not submitted any command for a predefined period), the user releases the connection session and it is added to a poll subset. The server monitors all the users in the pool subsets; as soon as a user in the poll subsets returns active by submitting a further command to the server, this command is processed by the first available connection session (until the access is released by the user of his/her motion or by the server after reaching the time-out period). In this way, it is possible to disassociate the accesses from the connection sessions, thereby increasing the number of accesses that can be granted concurrently.
However, the above-described approach is not of general applicability. Indeed, in many cases the connection sessions cannot be recycled by different users. Typically, this happens when each connection session maintains specific context information (for example, relating to the corresponding user); therefore, the context information (being lost when the user releases the connection session) should be recollected whenever the same user submits a further command that is processed by another connection session. This causes an overhead of the server, which may be untenable in most practical cases. A typical example is in the above-mentioned DAM applications, wherein a complex handshaking procedure is typically implemented to identify and validate each user before granting the required access.